由于传播、利用本公众号听风安全所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，公众号听风安全及作者不为此承担任何责任，一旦造成后果请自行承担！如有侵权烦请告知，我们会立即删除并致歉。谢谢！公众号现在只对常读和星标的公众号才展示大图推送，
建议大家把听风安全设为星标，否则可能就看不到啦！
----------------------------------------------------------------------
WebLogic是美国Oracle公司出品一款中间件产品，在国内使用也比较广泛。从2015年开始至今，接连爆出过10几个可直接利用的Java反序列化漏洞，相关漏洞的原理也越来越复杂。每次应急响应过程中，遇到Oracle公司的产品都会特别头疼，因为其日志结构太过繁杂，相关介绍文档也很少，想弄明白是需要下一番功夫的。在日常的应急响应过程中，为了解决这个问题，我曾经反复搭建环境，反编译各种Weblogic攻击工具，跟踪其源代码，研究可以不依赖日志分析去快速解决Weblogic中间件应急响应的方法，流量监控设备通常会有各种报警，混杂在一起的时候，也很难确定准确的攻击时间。对于早期Weblogic反序列化攻击，我做应急响应的时候，ls -lah看一下Weblogic几个目录下新增的文件及文件时间属性，就能判断出攻击者用的是哪一款Weblogic漏洞利用工具，而且还可以确定准确的攻击时间，根本就不用去看日志。下面分享一下这个技巧，后续也会花很大篇幅讲讲Weblogic的日志结构及各种漏洞的应急溯源技巧，因为牵扯到Oracle公司的产品，都会很复杂。花很大精力：使用Weblogic反序列化工具进行攻击，查看服务器的/temp/目录，会生成一个.tmp格式的临时文件，然后查看此文件属性，得知攻击者执行命令的准确时间。将此tmp文件拷贝出来，改扩展名为.jar，使用jadx-gui工具反编译，即可看到攻击代码，证明此文件确实是攻击者遗留下来的。很多weblogic反序列化利用工具为了能通过T3协议回显命令执行结果，都有类似的文件落地，也有的weblogic反序列化利用工具为了实现无文件落地回显，是通过defineClass方法，从byte[]字节码中还原一个Class对象，实现无文件落地注入构造回显，这种应急方法不再适用。应急方法讲完之后，接下来看一下相关工具为什么会向/temp/目录写文件，首先要大体讲一下T3反序列化回显的原理：Weblogic对外提供Web服务，会开放7001等端口，这个端口是Web协议、T3协议、IIOP协议并存的，而T3协议允许客户端远程调用Weblogic服务端的类，然后把执行结果再传输给客户端。因此攻击者会在本地事先编译好一个具有执行命令、上传文件等功能的java类，接着将编译好的文件上传至服务器上，通过URLClassLoader加载这个编译文件，在服务端绑定一个实例，进而实现T3下的Weblogic反序列化回显，其实有点类似于RMI远程方法调用的过程。 这里要指出，有的Weblogic利用工具向服务器写入临时文件时，并没有关闭文件句柄，导致文件会一直存在服务器上。 1 首先看第一款实现Weblogic反序列化回显的利用工具，是由冰蝎作者rebeyond大牛编写的。我记得大概是15年年底时，冰蝎作者rebeyond第一个公布出Weblogic T3反序列化回显方法，而且给出了相关的代码。后续的研究者的回显方法基本上与rebeyond的差不多，通过加载字节码方式实现无文件落地回显。
我们反编译一下rebeyond的工具，看看代码的具体实现过程：通过Connect按钮事件跟进，一直跟到GenPayload类的Gen方法，很明显可以看到，这款工具会向服务器的临时目录写入1vBLBK.tmp临时文件：之后再通过URLClassLoader类加载这个tmp文件，在服务端绑定一个实例，进而实现T3回显。 2 接下来看另一款Weblogic反序列化利用工具：利用成功后，会在服务器上生成H3y5ec.tmp临时文件。之后同样使用URLClassLoader类加载，实现T3回显。 3 接下来看第3款Weblogic反序列化利用工具：同样是使用URLClassLoader类加载，实现T3回显： Part3 总结
1. 早期的Weblogic反序列化利用工具，为了实现T3协议回显，都会向服务器上写入一个临时文件。近几年随着无文件落地的流行，Weblogic的回显基本上都是找一个实现了defineClass方法的类，通过还原字节码方式实现回显，这种应急方法不再适用。2. 应急溯源过程中，日志量通常浩如烟海，而且容易被攻击者删掉。在此情况，研究一下攻击者常用工具的原理，总结一些小技巧，在日常应急溯源工作中，会事半功倍，省去很大的工作量。